As computer systems continue to grow in size, and the capabilities available to end users via such systems continue to expand, there is an ever-increasing demand upon available resources. This is particularly true in the case of computer networks, where a common resource may be shared by a number of client computers. In such a situation, bottlenecks can occur during the execution of application programs that are being run by users on individual clients of the network. The ability to recognize and prevent such bottlenecks from occurring during the execution of application programs has a direct impact on the productivity of the users of the computer system. To this end, therefore, it is desirable to monitor the response time of an application program during execution, to identify potential bottlenecks. By doing so, available resources can be reallocated as necessary to ensure optimum performance.
In general, one indication of application performance is obtained by measuring the amount of time that is required to respond to a particular request made by or to an application program. To do so, it is therefore necessary to record the times at which the request is generated, and the response is returned. By measuring the latency between the recorded times, a metric is obtained that provides a good indicator of the application's performance. Depending upon the amount of information that is desired, different amounts of monitoring criteria can be established. For example, if a measure of gross latency is sufficient to monitor performance, it may only be necessary to record the time at which the request is initially generated and the time at which the ultimate response is returned. Alternatively, if more information is desired, a time can be recorded for each individual task that is carried out in responding to the request, such as opening windows, performing calculations, etc.
In the past, the recording of the time at which various events occur during the execution of an application program was accomplished by incorporating application programming interfaces (APIs) into the program whose performance was to be monitored. In essence, these programming interfaces provide a form of instrumentation that permit individual events in the execution of an application to be identified, so that the time of their occurrence can be recorded. One particular advantage of this approach is the fact that any amount of desired detail, at any given level of operation of the program, can be obtained.
However, there are various limitations associated with this "instrumented" approach. One of these is the fact that it is highly labor intensive, since it requires the program to be rewritten to incorporate the APIs. To do so, of course, requires access to the source code for the program. As a result, off-the-shelf programs that are typically sold in "shrink-wrapped" form cannot be adapted by the user to monitor their performance.
Recently, a standard set of APIs has been proposed to provide greater uniformity in performance monitoring. See "Application Response Measurement API Guide", May 1996. While these standard APIs can be readily incorporated into newly developed programs, they cannot be used with pre-existing programs unless the programs are rewritten to incorporate them. Again, therefore, significant effort must be expended to be able to monitor such programs.
A different, but related, approach is disclosed in U.S. Pat. No. 5,485,574. In the system of this patent, a facility is provided in the kernel of the computer's operating system to count instructions or calls to sections of program code. While this approach avoids the need to incorporate APIs into individual application programs, it still requires that a program, in this case the kernel of the computer's operating system, be modified to provide the necessary instrumentation. In addition, results are obtained at the kernel level of the operating system, rather than at the application or user level.
As an alternative to the instrumented approach that requires customization of an individual program, another technique for monitoring the performance of a system relies upon network-based communications. Typically, communications between an application program running on a client station and a network server are transmitted via individual data packets. All of the packets pertaining to a given application program are transmitted through a logical port associated with the server. In the network-based approach to monitoring, all packets which pass through a given port are opened, and examined, to determine the types of actions to which they pertain. If a packet contains data relating to a task of interest, the time at which that packet passes through the port is recorded. The advantage of this approach is that it does not require any modification of the application program, and theoretically is applicable to all available programs. However, the results provided by this approach are not completely accurate. In particular, the examination of the data packets takes place along the communication path between the client station and the network server. As such, the times which are recorded in association with each packet only reflect the instance at which the packet passes through the designated port. They do not include additional processing time that may be encountered by the packet after it passes through the port but before the final result is delivered to the requesting application. As another consideration, the examination of the packets is typically carried out by a machine that is separate from the client station, and hence this approach presents increased hardware expenses. Furthermore, in order to examine the individual packets, the network interface card must operate in a promiscuous mode to permit the port traffic to be examined. Since this mode of operation permits external entities to access the packets, security is compromised.
It is desirable, therefore, to provide a non-instrumented monitor which does not need to be incorporated into specific programs, and thereby permits the performance of any program to be monitored without modification thereof. Further in this regard, it is desirable to provide such a system which is client-based, so that it provides a true measure of the response time associated with a given task.